A computer network is a collection of interconnected devices that can exchange data and share resources according to one or more communication protocols. The communication protocols define the format and manner in which the devices communicate the data. Example protocols include the Transmission Control Protocol (TCP) and the Internet Protocol (IP) that facilitate data communication by dividing the data into small blocks called packets. These packets are individually routed across the network from a source device to a destination device. The destination device extracts the data from the packets and assembles the data into its original form. Dividing the data into packets enables the source device to resend only those individual packets that may be lost during transmission. The protocols define the format and construction of the packet, including header and payload portions of the packets.
Periodically, it is necessary to transition from one communication protocol to another. This may occur, for example, when a current communication protocol used within a network is upgraded to a newer version. As one example, the Internet is currently based on a communication protocol known as Internet Protocol version 4 (IPv4). IPv4 offers a ubiquitous network service, based on datagram (connectionless) operation, and on globally significant IP addresses to aid routing. It is becoming clear that certain elements of IPv4 are insufficient to support the growth of the Internet. For example, IPv4 makes use of a 32-bit address space. Internet Protocol version 6 (IPv6), however, makes use of a much larger 128-bit address space. However, development, standardization, implementation, testing, debugging and deployment of a new communication protocol can take a very large amount of time and energy, and is not guaranteed to lead to success.
A variety of approaches may be used in an attempt to provide a smooth transition from one communication protocol to another. For example, one approach makes use of encapsulation. Packets conforming to the new communication protocol, for example, may be encapsulated within packets conforming to the old communication protocol for transmission via devices or other network resources that do not yet support the new communication protocol. One example of such a protocol, commonly referred to as the “6 to 4” protocol, is described in Request for Comments (“RFC”) 3056, entitled “Connection of IPv6 Domains via IPv4 Clouds” to K. Moore, February 2001, the entire content of which is incorporated herein by reference. In general, the 6 to 4 protocol relies upon 6 to 4 relays that encapsulate an IPv6 packet within an IPv4 packet prior to forwarding the IPv4 packet along an IPv4 network and decapsulate an IPv6 packet from an IPv4 packet prior to forwarding the IPv6 packet along an IPv6 network. According to the 6 to 4 protocol, the IPv6 network address of the 6 to 4 host included within the header of the IPv6 packet includes an IPv4 address of the 6 to 4 host appended to a well-known “6 to” IPv6 header that is the same for all 6 to 4 hosts.
However, according to the 6 to 4 protocol, all IPv6 packets include the same well-known IPv6 header and, thus, may be processed by any 6 to 4 relay managed by any Internet Service Provider (ISP). Therefore, there is no guarantee that all native IPv6 hosts have a functioning route to a 6 to 4 relay. There is also no guarantee that a 6 to 4 host is reachable by all native IPv6 hosts. Furthermore, the ISP that operates a 6 to 4 relay has no control over which hosts use the 6 to 4 relay, which limits the inceptive to maintain a high quality of service as traffic grows. In some examples, the ISP may elect not to forward any traffic that does not include a source or destination address that is outside of the network addresses associated with the ISP, resulting in packet loss.
Another example of a protocol that makes use of encapsulation to provide a smoother transition from IPv4 to IPv6 is described in RFC 5569, entitled “IPv6 Rapid Deployment on IPv4 Infrastructures” to R. Despres, January 2010, the entire content of which is incorporated herein by reference, and is commonly referred to as the “6rd” protocol. In general, the 6rd protocol relies upon 6rd relays that encapsulate and decapsulate packets similarly to the 6 to 4 protocol. In contrast to the 6 to 4 protocol, the 6rd protocol requires that an IPv6 network address associated with the IPv6 packet includes the IPv4 address of the 6rd host appended to an IPv6 header that is uniquely defined for each ISP. Because the IPv6 header is defined for each ISP, each ISP may guarantee that each 6rd host (e.g., an end user device that implements the 6rd protocol) will be reachable from all native IPv6 hosts. Furthermore, each ISP maintains full responsibility for the quality of service experience by its own customers because each relay server responsible for processing packets having the IPv6 header defined for each ISP is within each ISP's control.
However, while the 6 to 4 protocol is widely implemented, the 6rd protocol is not as widely implemented. For example, various versions of the Windows® operating system developed by Microsoft® (e.g., Windows® 7) as well as various version of the OS X operating system developed by Apple® (e.g., OS X Snow Leopard®) implement the 6 to 4 protocol, but do not implement the 6rd protocol. The limitations of the 6 to 4 protocol described above combined with the minimal implementation of the 6rd protocol make it difficult for ISPs to deploy IPv6 to end users.